Data Fusion for Multimodal Traveler Information in a Wireless Environment

This paper presents two aspects of data fusion for a multimodal traveler information application. The two aspects are: (1) system architecture and (2) analytical estimation of the state variable speed from the observed quantities Volume and Occupancy. The paper describes how the analytical estimation procedure is integrated into the overall architecture INTRODUCTION In this paper, we describe a structured approach to developing an Intelligent Transportation System (ITS) data fusion application. We use this approach to develop a distributed computing application that is suitable for distributing dynamic data in real time to a large group of users. Our discussion focuses on two aspects of data fusion for traveler information. The first aspect is the communication architecture which provides support for multiple data sources and sinks. The second aspect is the specific data fusion algorithm, which estimates mean vehicle speeds using single inductance loops sensors. These two aspects of data fusion are combined and used to demonstrate how a specific algorithm is implemented in the context of the overall data fusion architecture of an ITS application. The application under consideration was created and deployed in support of a wireless Multimodal traveler information system, the Seattle Wide-area Information for Travelers (SWIFT) project, a federal highway administration (FHWA) operational test (FOT). The paradigms used in developing the SWIFT data fusion application fit within the context of the FHWA ITS Architecture ( 1, 2) COMMUNICATIONS ARCHITECTURE Our development environment is composed of four software components that can be configured and linked to construct applications. The components constitute a toolkit that implicitly handles messages and communication, freeing developers to deal with the flow and interpretation of data streams. Each component is: (1) autonomous, i.e. components are distributed across computing platforms; (2) independent, i.e. components can operate in parallel; (3) a peer of any other component, i.e. components can be placed into an evolving hierarchical matrix with great flexibility; and (4) reusable, i.e. coding is efficient and much of the application design is reduced to configuring available components. There are four types of components, each of which affects the flow of data. The component types are: (1) a Source Component, which makes a data stream available, (2) a Redistributor Component, which obtains a data stream from one component and redistributes it to one or more other components, (3) an Operator Component, which obtains data streams from one or more components and creates a new data stream for distribution to one or more components, and (4) a Sink Component, which obtains data streams from one or more components. Redistributors and Operators function both as client and server, while Sources are servers and Sinks are clients. We use the existing network inter-process communication (IPC) facilities as a base for implementing the components that make up the building blocks of our application development environment. Unlike previous work that required extensive software for each participating operating environment, we require only a socket interface to an IPC library to implement applications on a wide variety of operating systems at low cost. Implicit in the use of the IPC services is the expectation that the appropriate guarantee of delivery and re-assembly is met. In the example presented here, the transmission control protocol/internet protocol (tcp/ip) is used to provide the transport layer services implicit in the use of IPC services. The use of a network-wide transport protocol implies that the application can be widely distributed geographically while guaranteeing connectivity. Problems associated with interoperability, compatibility, and addressing are invisible to the applications discussed here because the transport mechanisms supporting the IPC paradigm address these issues directly. In the following sections, we describe each of our component types.